Amendments to the Specification: 

Please amend the paragraph beginning on line 17 of page 10 of the application to read as 
follows: 

As shown in Fig. 3, a regional data center 16 comprises front-end equipment to receive 
an input from a satellite receiver and/or terrestrial signal receiver and to output content to users 
20 of Fig. 1, or control/feedback signals for transmission to the NOC 28 of Fig. L or another 
hierarchical component in the network 10 of Fig. L via wireline or wireless communication 
network , such as 33 of Fig. 1 . Specifically, a regional data center 16 preferably has more 
hardware than a media serving system 14 such as gigabit routers and load-balancing switches 66 
and 68, along with high-capacity servers (e.g., plural media serving systems 14) and a storage 
device 62. The CPU 60 and host 64 are operable to facilitate storage and delivery of less 
frequently accessed on-demand content using the servers 14 and switches 66 and 68. 

Please amend the paragraph beginning on line 26 of page 10 through line 3 of page 1 1 of the 
appHcation to read as follows: 

As discussed in more detail below, the regional data centers 16 also deliver content to a 
user 20 if a standalone media serving system 14 is not available to that particular user 20, or if 
that media serving system 14 does not include the content requested by the user 20. That is, the 
director at the encoding facility 28 preferably continuously monitors the status of the standalone 
media serving systems 14 and reroutes users 20 to the nearest regional data center 16 if the 
nearest media serving system 14 fails, reaches its fulfillment capacity or drops packets. Users 20 
are typically assigned to the regional data center 14 16 of Fig. L that corresponds with the 



#273604v2 



2 



Internet backbone provider that serves their ISP, thereby maximizing performance of the second 
tier of the distribution network 12 of Fig. 1 . The regional data centers 44 16 of Fig. 1, also serve 
any users 20 of Fig. L whose ISP does not have an edge server. 

Please amend the paragraph beginning on line 4 of page 1 1 of the application to read as follows: 

The master data centers 18 are similar to regional data centers 16, except that they are 
preferably much larger hardware deployments and are preferably located in a few peered data 
centers and co-location facilities, which provide the master data centers with connections to 
thousands of ISPs. Therefore, Fig. 3 is also used to illustrate an example of components 
included in a master data center 18. However, it is noted that a master data center 18 comprises 
multiterabyte storage networks (e.g., a larger number of media serving systems 14) to manage 
large libraries of content created, for example, by major media companies. As discussed in more 
detail below, the director at the encoding facility 28 automatically routes traffic to the closest 
master data center 18 if a media serving system 14 or regional data center 16 is unavailable to a 
user, or if the user has requested content that is not available at its designated media serving 
system 14 or regional data center 16. The master data centers 18 can therefore absorb massive 
surges in demand without impacting the basic operation and reliability of the network. 

Please amend the paragraph beginning on line 17 of page 1 1 of the application to read as 
follows: 

The flow of data and content will now be discussed with reference to Figs. 4-8. As 
shown in Figs. 4 and 5 5A-5D , the intemet broadcast network 10 for streaming media generally 
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comprises three phases, that is, acquisition 100 of Fig. 5A , broadcasting 102 of Fig. 5B. and 
receiving 104 of Figs. 5C and 5D , In the acquisition phase 100, content is provided to the 
network from different sources such as internet content providers (ICPs) or event or studio 
content sources 24, as shown in Fig. 1. As stated previously, content can be received from audio 
and/or video equipment employed at a stadium for a hve broadcast. The content can be, for 
example, live analog signals, live digital signals, analog tape recordings, digitally stored 
information (e.g., media-on-demand or MOD), among other types of content. The content can 
be locally encoded or transcoded at the source using, for example, file transport protocol (FTP), 
MSBD or real-time transport protocol/ real-time streaming protocol (RTP/RTSP). 

Please amend the paragraph beginning on line 28 of page 1 1 through line 8 of page 12 of the 
application to read as follows: 

The content is collected using one or more acquisition modules 106 which are described 
in more detail below in connection with Fig. 6. The acquisition modules 106 represent different 
feeds to the network 10 in the acquisition network 22 shown in Fig. 1 and the components of the 
acquisition modules 106 can be co-located or distributed throughout the acquisition network 28 
22. Generally, acquisition modules 106 can perform remote transcoding or encoding of content 
using FTP, MSBD, or RTP/RTSP or other protocols prior to transmission to a broadcast module 
1 10 for multicast to edge devices and subsequent rendering to users 20 ofFig. L located 
relatively near to one of the edge devices. The content is then converted into a broadcast packet 
in accordance with an embodiment of the present invention. This process of packaging packets 
in a manner to facilitate multicasting, and to provide insight at reception sites as to what the 
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packets are and what media they represent, constitutes a significant advantage of the network 10 
over other content delivery networks. 

Please amend the paragraph beginning on line 9 of page 12 of the application to read as follows: 

Content obtained via the acquisition phase 100 is preferably provided to one or more 
broadcast modules 1 10 via a multicast cloud or network(s) 108. The content is unicast or 
preferably multicast fi-om the different acquisition modules 106 to the broadcast modules 1 10 via 
the cloud 108. As stated above, the cloud 108 is preferably a point-to-multipoint broadcast 
backbone. The cloud 108 can be implemented as one or more of a wireless network such as a 
satellite network or a terrestrial or wireline network such as optical fiber link. The cloud 108 can 
employ a dedicated ATM link or the internet backbone, as well as a satellite link, to multicast 
streaming media. The broadcast modules 1 10 are preferably in ti e r 120, that is, th e y ar e at the 
encoding center 28 that receive content fi-om the acquisition modules 106 and, in turn, broadcast 
the content via satellite 32 of Fig. 1 , ATM/Litemet network 33 of Fig. L or both, to receivers at 
the media serving systems 14, regional data centers 16, and master data centers 18 (see Fig. 1) in 
tiers 116, 118 and 120, respectively (see Fig. 5 12). 

Please amend the paragraph beginning on line 22 of page 13 through line 1 1 of page 14 of the 
application to read as follows: 

Acquisition for plural customers A through X is illustrated in Fig. 6. By way of an 
example, acquisition for customer A involves an encoder, as indicated at 134, which can employ 
Real, WMT, MPEG, QT, among other encoding schemes with content from a source 24. The 
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encoder also encodes packets into a format to facilitate broadcasting in accordance with the 
present invention. A disk 130 stores content from different sources and provides MOD streams, 
for example, to a disk host 132. The disk host 132 can be proxying the content or hosting it. 
Live content, teleconferencing, stock and weather data generating systems, and the like, on the 
other hand, is also encoded. The disk host 132 imicasts the MOD streams to a file transport 
module 136, whereas the encoder 134 provides the live streams to a transport sender 138 via 
unicast or multicast. The encoder can employ either unicast or multicast if QT is used. 
Conversion from unicast to multicast is not always needed, but multicast to multicast unicast-to- 
multicast conversion can be useful. The file transport module 136 transfers MOD content to a 
multicast-enabled network. The transport sender 138 pulls stream data from a media encoder 
134 or an optional aggregator and sends stream announcements (e.g., using session 
announcement protocol and session description protocol (SAP/SDP)) and stream data to 
multicast intemet protocol (IP) addresses and ports received from a transport manager, such as 
170 of Fig. 9. which is described in more detail below with reference to Fig. 9. When a Real G2 
server is used to push a stream, as opposed to a pulling scheme, an aggregator can be used to 
convert from a push scheme to a pull scheme. The components described in connection with 
Fig. 6 can be deployed at the encoding center 28 or in a distributed maimer at, for example, 
content provider facilities. 
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Please amend the paragraph beginning on hne 12 of page 14 of the appUcation to read as 
follows: 

Fig. 5 7 illustrates an exemplary footprint for one of a plurality of broadcasts. As shown 
in Fig. 5 7, the broadcasting phase 102 is implemented using a transport broadcaster 140 and a 
transport bridge 142. These two modules are preferably implemented as one software program, 
but different functions, at a master data center 18 or network operations center. The transport 
broadcaster 140 performs transport path management, whereas the transport bridge 142 provides 
for peering. The broadcaster 140 and bridge 142 get data from the multicast cloud (e.g., network 
108) being guided by the transport manager and forward it to an appropriate transport path. One 
transport broadcaster 140, for example, can be used to represent one transport path such as 
satellite uplink or fiber between data centers or even a cross-continental link to a data center in 
Asia from a data center in North America. The broadcaster 140 and bridge 142 listen to stream 
aimouncements from transport senders 138 of Fig. 6. and enable and disable multicast traffic to 
another transport path, accordingly. They can also tunnel multicast traffic by using TCP to send 
stream information and data to another multicast-enabled network. Thus, broadcast modules 110 
transmit corresponding subsets of the acquisition phase streams that are sent via the multicast 
cloud 108. In other words, the broadcast modules 110 operate as gatekeepers for their respective 
transport paths, that is, they pass any streams that need to be sent via their corresponding path 
and prevent passage of other streams. 
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Please amend the paragraph beginning on line 30 of page 14 through line 10 of page 15 of the 
application to read as follows: 

As stated above, Fig. 8 illustrates an example the reception phase 104 at one of a plurality 
of servers or data centers. As stated above, the data centers are preferably deployed in a tiered 
hierarchy comprising media serving systems 14, regional data centers 16^ and master data centers 
18 , each of Fig. L The tiers 1 16, 1 18 and 120^ each of Fig. 12, comprise a transport receiver 
144. Transport receivers can be grouped using, for example, the transport manager 170 of Fig. 9 . 
Each transport receiver 144 receives those streams from the broadcast modules 110 that are 
being sent to a group to w^hich the receiver belongs. The transport receiver listens to stream 
announcements, receives stream data from plural transport senders 138 of Fig. 6, and feeds the 
stream data to media servers 146. The transport receiver 144 can also switch streams, as 
indicated at 154 (e.g., to replace a live stream with a local MOD feed for advertisement insertion 
purposes). The MOD streams are received via the file transport 136 of Fig. 6, and stored^ as 
indicated via the disk host 148, database 150 and proxy cache/HTTP server 152. The servers 
146 and 152 can provide content streams to users 20. 

Please amend the paragraph beginning on line 17 of page 15 through line 2 of page 16 of the 
application to read as follows: 

The transport manager 170 will now be described with reference to Fig. 9 which 
illustrates an overview of transport data management. The transport manager is preferably a 
software module deployed at the encoding facility 28 or other facility designated as a NOC. 
Multiple content sources 24 (e.g., database content, programs and applications) provide content 
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as input into the transport manager 170. Information regarding the content from these data 
sources is also provided to the transport manager such as identification of input content source 
24 and output destination (e.g., groups of receivers). Decisions as to where content streams are 
to be sent and which groups of servers (e.g., tiers 1 16, 1 18 or 120) are to receive the streams can 
be predefined and indicated to the transport manager 170 as a configuration file or XBM 
ftmction call in real-time, for example, under control of the director as discussed in more detail 
below. This information can also be entered via a graphical user interface (GUI) 172 or 
command hne utihty. In any event, the information is stored in a local database 174. The 
database 174 also stores information for respective streams relating to defined maximum and 
minimum IP address and port ranges, bandwidth usage, groups or communities intended to 
receive the streams, network and stream names, as well as information for user authentication to 
protect against unauthorized use of streams or other distributed data. 

Please amend the paragraph beginning on Une 20 of page 16 of the application to read as 
follows: 

As discussed above a n, and in more detail below, once the transport sender 138 
commences sending the stream into the assigned multicast IP address and port, the transport 
broadcaster 140 of the corresponding broadcast module 1 10 (see Fig. 7) will filter the stream. 
The transport receiver 144 of the appropriate tier or tiers 1 16, 1 18 or 120 (see Fig. 8) joins the 
multicast IP address and receives the data or stream if the stream is intended for a group to which 
the receiver 144 belongs. As stated above in connection with Fig. 8, the transport receiver 144 
converts the steam received via the cloud 108 and sends it to the media server available to the 
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users 20. The data is then provided to the media server associated with the receiver. Receivers 
144 and broadcasters 140 track announcements that they have honored using link lists. 

Please amend the paragraph beginning on line 30 of page 16 through line 3 of page 17 of the 
application to read as follows: 

As stated above, the transport components preferably use RPT RTP as a data transport 
protocol. Accordingly, Windows Media, RealG2 and QT packets are wrapped into RTP packets. 
The acquisition network 22 of Fig. 1, preferably employs an RTP stack to facilitate processing 
any data packets, wrapping the data packets with RTP header and sending the data packets. 
RTSP connection information is generally all that is needed to commence streaming. 

Please amend the paragraph beginning on Une 19 of page 18 of the application to read as 
follows: 

The manner in which streams and content are distributed throughout the tiers 116, 118 
and 120 will now be further described with reference to Figs, 10 and 11 10-12 . 

Please amend the paragraph beginning on line 21 of page 18 through line 2 of page 19 of the 
application to read as follows: 

As discussed above, the master data centers 18 of Fig. 12 are configured to support 
enormous numbers of requests for streaming media and thus, is the first tier 120 of Fig. 12, of 
redundancy for handling requests by end users from the Internet in general. The regional data 
centers 16 of Fig. 12 make up the second tier 118 of Fig. 12, and are strategically disposed at 
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major "backbone" points across the Internet. The regional data centers 16 service traffic from 
within one subnetwork on the Internet to use within the same subnetwork, thus preventing the 
content of the data from being subjected to problems and idiosyncrasies associated with private 
and public peering which can occur on the Internet as can be appreciated by one skilled in the 
art. The regional data centers 16 are also capable of serving high volumes of data streams. The 
media serving systems 14 of Fig. 12 . which make up the third tier 1 16 of the network WO 12 of 
Fig. 12 , are disposed within the access providers' points of presence (POPs) which are generally 
less than two router hops away from the end user. These media serving systems 14 are generally 
not subject to any of the idiosyncrasies of the Internet, and thus can be scaled to meet the needs 
of the specific POP. 

Please amend the paragraph beginning on line 3 of page 19 of the apphcation to read as follows: 
The master data centers 1 8, in conjunction with the encoding facility 28 of Fig. L includ e 
a includes the a director 200 , which includes a distributed server application. The director 200 
can poll information about the network 10 of Fig. L from a plurality of sources in the network 10 
from other directors present at the regional data centers 16 and media serving systems 14, and 
can use this information to determine or modify the positions in the streaming data at which data 
received from content providers should be placed, so as to best distribute that data to the regional 
data centers 16 and media serving systems 14. 

Please amend the paragraph beginning on line 10 of page 19 of the application to read as 
follows: 
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Referring to Fig. 1, under control of the director 200 of Fig. 10 , the encoder 28 uplinks 
data received from content providers to the master data center or centers 18, the regional data 
servers 16 and the media serving systems 14 via satelHte 32, ATM/Intemet network 33, or both. 
The components of the network 10 cooperate as discussed above to insure that the correct 
multicast stream reaches every server in the network 10. Also, the satellite delivery of the data 
leverages the economy of scale realizable through known broadcast technology, and further, 
bypasses the slower and costlier terrestrial backbone of the Internet to provide the end user with 
consistent and faster Internet performance, which results in lower bandwidth costs, better quality 
of service, and offer new opportunities. The package delivery software employed at the 
encoding facility allows the data files to be distributed by multicast UDP/IP, TCP/IP, or both, as 
can be appreciated by one skilled in the art. Also, the package dehvery software includes a 
queuing server as well as a retransmission server that cooperate to transmit the data and quickly 
recover any lost data packets. This recovery scheme results in smoother delivery of streaming 
audio, video and multimedia data to the Internet. 

Please amend the paragraph beginning on line 24 of page 19 through line 2 of page 20 of the 
application to read as follows: 

The encoding facility 28 distributes content to tiers 116, 118 and 120 to insure that the 
data from the content providers are efficiently and cost-effectively multicast out to all three tiers 
of the network 10 simultaneously. As shown in Fig. 10, the director constantly monitors the 
network and adapts to changes, ensuring the quality of applications run on the network 10. As 
further shown, relay software 202 is distributed throughout the network 10 to provide a reliable 
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transport layer that makes sure no packets get lost across the broadcast backbone. The transport 
layer also lets applications scale connections from one-to-few to one-to-many. In addition to 
receiving and unpacking data from the broadcast backbone, the relay software 202 manages local 
storage and reports to the director 200 on the status of the remote server in its applications. 
Please amend the paragraph beginning on line 26 of page 23 through line 5 of page 24 of the 
application to read as follows: 

However, according to an embodiment of the present invention, when a client 192 
requests a generic metafile/media, the request is received by a redirector 194 which, under 
control of the director as described above, redirects the request to an interceptor (server) 196. 
The interceptor requests the metafile or media resource from the centralized web or other media 
server 198 via the network cloud W 182 . The centralized web server i94 184 , or other media 
server 198, receives either the statically generated metafile from the file storage disk 186 or the 
dynamically generated metafile from the CGI/program 188, and transmits the metafile or 
protocol response back to the client 192 via the network cloud 182. However, before the 
metafile or protocol response is delivered to the client 192, the redirector 194, under control of 
the director, analyzes the information contained in the metafile and changes it accordingly. For 
example, the metafile may be rewritten to change the links pointing to local server 190 to point 
to a different local server 198. 

Please amend the paragraph beginning on line 13 of page 25 of the application to read as 
follows: 

Full Decision Scenario #3 

User C (see Fig. 12) requests a 300kb Windows Media Stream 
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Network Availability: 
Server Availability: 
Stream Availability: 
Stream Bandwidth: 
Server Performance: 
Result: 



True to Edge #i 4, Master #1 ; False to Master #2 
Edge #i 4 Master #1 
Stream exists on both Servers 

Edge #i 4 can serve stream bandw^idth; Master #1 can't 

Edge #i 4 available to serve stream 

User directed to Windows Media Server in Edge #i 4 
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